On the World Wide Web (i.e., the “web”), it is frequently desirable for websites to store information relating to a specific user and/or user computer. In many applications, it is necessary, or at least desirable, to associate a user computer with context data relating to previous interactions with that same user computer. For example, a user may indicate certain preferences regarding the display of a particular website, and it may be desirable to associate those preferences with the user computer for future visits. However, the standard protocol for transferring web pages—the HyperText Transport Protocol (HTTP)—has a limited capability for storing user computer-specific context data across visits.
Known methods for storing user computer-specific context data built into HTTP usually involve storing a small segment of data, called a “magic cookie” (or simply “cookie”) on the user computer. Cookies form the building blocks for most user computer-specific context data storage on the web, but they have several limitations. Cookies are limited in size, finite in quantity, and can be arbitrarily modified or deleted by the user. They also pose privacy and security concerns, which limit their suitability for storage of many kinds of context data that would be desirable to store. For example, it may be desirable for a website to automatically store a user's personal information for the purpose of facilitating future visits from the same user, but storing the user's personal information in a cookie makes the information potentially vulnerable to disclosure or malicious modification by other programs or websites, yielding an undesirable result.
Other techniques for storing data on the user computer include ASP.NET View State, hidden form fields, and URL query strings. However, these techniques are limited in the amount of data they can store and many of them threaten the security of the user computer when used to store critical data.
To address these concerns, many web servers use cookies (or other techniques) to store index data in the user computer. This index data is then used to retrieve the user computer-specific context data from a database of context data stored at the web server. The user computer-specific context data can be stored securely at the web server while still being uniquely associated with various user computers through use of cookies.
While the technique of using index data contained in cookies to retrieve context data stored at the web server is an improvement over storing context data in cookies directly, it introduces several other problems when put into practice.
Web servers are highly active systems with many processes running in parallel. It is quite common for web servers to crash, freeze, restart, or slow due to high volume of traffic. These events can make the website and any stored context data unavailable for a period of time, and, in some cases, result in the loss of context data entirely.
Now referring to FIG. 1, to alleviate the effect of server failure, it is common for websites to be hosted on multiple web servers 24, 26, 28. Many websites receive such a high volume of page requests that without hosting them on multiple web servers, the response time to page requests would be intolerable. Having multiple web servers 24, 26, 28 reduces the likelihood that the website will become unavailable due to a server failure and increases the overall capability of the system to handle a high volume of page requests received via some network 20 from one or more user computers 12, 14, 16, 18. A load balancer 22 has been known to be implemented for evenly assigning incoming web page requests to one of the array of web servers 24, 26, 28. Load balancing techniques are designed to smooth the response to page requests despite server delays or failures.
However, load balancing does not address the problem of potential context data loss due to server failure. If context data is stored on a web server that fails, load balancing techniques may be able to continue web service without interruption, but the context data stored on that web server may be lost. Load balancing alone does not protect context data from server loss.
Furthermore, storing context data on web servers may hinder load balancing. If the user computer-specific context data is stored on a certain web server, it is necessary that return visits by the user computer be handled by the same web server so as to facilitate retrieval of the context data. Thus, the user computer remains associated with a particular web server, even though load conditions may have changed, causing another server to have greater availability of capacity. This static association between a user computer and a web server reduces the effectiveness of load balancing. Load balancing techniques have difficulty assigning page requests to web servers evenly when a large portion of incoming page requests must necessarily be assigned to a specific web server.
Additionally, storing context data on a web server poses challenges for maintaining or upgrading the web server, as context data can persist for long periods of time and it is not generally known when the return of a certain user computer will necessitate access to certain context data. Thus, referring again to FIG. 1, context data has been known to be stored in a context data store 30 external to the web servers 24, 26, 28. However, storing context data external to one or more of the web servers 24, 26, 28 introduces several extra steps. In order to process a request, a web server must receive the request, determine the need for context, request the context data from the external context data store 30, wait for a response, process that response, write the updated context data back to the external context data store 30, and finally return the web request. These extra steps introduce delay, complexity, and the potential for failure.